mailboxes: в SQL-базе?
Lev Serebryakov
А есть ли какие-нибудь противопоказания для того, что бы хранить почту в
mySQL/PostgreSQL?
Я вижу только одно: локальные пользователи & /usr/bin/mail.
Hо, с друголй стороны, если пользователи POP3/IMAP only, или пользуются
клиентами, умеющими POP3/IMAP, а не только /var/mail?
А плюсов много: и нет проблем с локом, и при грамотной организации базы нет
проблем с производительностью при просмотре заголовков через TOP (и что там для
этого в IMAP), etc.
Есть ли готовые решения (локальный доставщик и pop3-демон)?
Или я не вижу каких-то подводных камней?
Remember, pain is part of pleasure, All.
... Во всех краях - дождь, встречным посигнальте,/Укажите им дорогу в никуда.
Dmitriy Yermakov
At 01 Jun 03 22:28:26, Lev Serebryakov wrote to All:
LS> А есть ли какие-нибудь противопоказания для того, что бы хранить почту
LS> в mySQL/PostgreSQL?
LS> Я вижу только одно: локальные пользователи & /usr/bin/mail.
LS> Hо, с друголй стороны, если пользователи POP3/IMAP only, или пользуются
LS> клиентами, умеющими POP3/IMAP, а не только /var/mail?
LS> А плюсов много: и нет проблем с локом, и при грамотной организации базы
LS> нет проблем с производительностью при просмотре заголовков через TOP (и
LS> что там для этого в IMAP), etc.
LS> Есть ли готовые решения (локальный доставщик и pop3-демон)?
/dyer
Peter V. Chernikoff
Hi, Lev!
On 01 Jun 2003 at 21:28, "LS", Lev Serebryakov wrote:
LS> What do you think about sharp blades, All? А есть ли какие-нибудь
LS> противопоказания для того, что бы хранить почту в mySQL/PostgreSQL? Я
LS> вижу только одно: локальные пользователи & /usr/bin/mail. Hо, с
LS> друголй стороны, если пользователи POP3/IMAP only, или пользуются
LS> клиентами, умеющими POP3/IMAP, а не только /var/mail? А плюсов много:
LS> и нет проблем с локом, и при грамотной организации базы нет проблем с
LS> производительностью при просмотре заголовков через TOP (и что там для
LS> этого в IMAP), etc.
У меня юзеpы с паpолями и пpочим в SQL, а сама почта в Maildir. Пpоблем с
локами тоже нет.
LS> Есть ли готовые решения (локальный доставщик и pop3-демон)?
Уй, сомневаюсь.
LS> Или я не вижу каких-то подводных камней?
Угу. Hайти POP3/IMAP сеpвеp, умеющий из SQL pаздавать почту.
--
WBR, Peter V. Chernikoff Home: +7 (926) 203-9532
mailto: peter not jgr.pp.ru Office: +7 (095) 213-5665
Alexander Kolesnikoff
> What do you think about sharp blades, All?
>
> А есть ли какие-нибудь противопоказания для того, что бы хранить почту в
> mySQL/PostgreSQL?
> Я вижу только одно: локальные пользователи & /usr/bin/mail.
> Hо, с друголй стороны, если пользователи POP3/IMAP only, или пользуются
> клиентами, умеющими POP3/IMAP, а не только /var/mail?
> А плюсов много: и нет проблем с локом, и при грамотной организации базы нет
> проблем с производительностью при просмотре заголовков через TOP (и что там для
> этого в IMAP), etc.
>
> Есть ли готовые решения (локальный доставщик и pop3-демон)?
>
> Или я не вижу каких-то подводных камней?
Ключевой момент - надёжность. Классичекий пример - MS Exchange.
Пример из жизни: на восстановление работы MS Exch после аварии с
диском, система на 5000 пользователей, ушло ~ 7 часов, при полном
отсутствии почтовых сервисов. Систему с постфиксом плюс чего-то на
12000 пользователей восстановили за 2 часа при частично работающем
POP3.
Alexander
Valentin Nechayev
>>> Lev Serebryakov wrote:
LS> А есть ли какие-нибудь противопоказания для того, что бы хранить почту в
LS> mySQL/PostgreSQL?
Были в наших краях такие любители извращений. Freemail на таком движке держали.
После того, как тазик упал, восстановитель mysql'евой базы (myisamchk,
кажется, тогда был) сказал, что ему нужно столько же места, сколько занимает
база сейчас, база занимала 16G, а свободно было в системе около 4G -
админ вначале потратил час на беготню по окрестностям в поисках 20G винта
для операции восстановления, а потом ушёл в размышления о габаритах
подложенной под него свиньи.
Я собственно о чём - даже если эту проблему преодолеешь, использовать SQL
базу в качестве хранителя безразмерных BLOB'ов - извращение.
Файловая система с этой ролью справляется лучше.
LS> Я вижу только одно: локальные пользователи & /usr/bin/mail.
Никто не мешает отделить такое хранилище от локальной почты и на отдельный
домен. У тебя же не свалка сплошь шелловых пользователей с такой почтой?
LS> Hо, с друголй стороны, если пользователи POP3/IMAP only, или пользуются
LS> клиентами, умеющими POP3/IMAP, а не только /var/mail?
LS> А плюсов много: и нет проблем с локом, и при грамотной организации базы нет
LS> проблем с производительностью при просмотре заголовков через TOP (и что там для
LS> этого в IMAP), etc.
Чтобы не было проблем с локами - делай maildir.
Чтобы не занимать лишнее место - FS, умеющая фрагменты, как фрёвая UFS.
Индексы всех видов можно хранить в базе.
С IMAP'ом сложнее - тут ещё MIME структуру письма уметь надо. Фактически -
представлять дерево разбора для каждого письма. Подход имени UMT - каждый
MIME entity в отдельном каталоге - тут чрезмерен. Укладывать дерево в RDBMS -
тоже изврат. Ищи золотую середину...
-netch-
Vladimi...@ukr.net
LS> А есть ли какие-нибудь противопоказания для того, что бы хранить почту в
LS> mySQL/PostgreSQL?
dbmail
LS> Я вижу только одно: локальные пользователи & /usr/bin/mail.
LS> Hо, с друголй стороны, если пользователи POP3/IMAP only, или пользуются
LS> клиентами, умеющими POP3/IMAP, а не только /var/mail?
LS> А плюсов много: и нет проблем с локом, и при грамотной организации базы нет
LS> проблем с производительностью при просмотре заголовков через TOP (и что там для
LS> этого в IMAP), etc.
сомнительно весьма
LS> Есть ли готовые решения (локальный доставщик и pop3-демон)?
LS>
LS> Или я не вижу каких-то подводных камней?
До 1к юзеров (работающих онлайн не больше 10%) - вполне реально, дальше -
кырдык. Возможности SQL слишком универсальны.
--
VVS56-RIPE
Ilya Kulagin
Однажды 01 Jun 03 22:28:26, Вы изволили написать к All:
LS> А есть ли какие-нибудь противопоказания для того, что бы хранить почту
LS> в mySQL/PostgreSQL?
Только одно. Если производительности не жаль, так делать можно. Для примера -
прошу взглянуть на Лотус или Эксчендж, которые именно этим всю жизнь и
занимаются. Агент, отжирающий 200М оперативки и 10% проца на 2*P3-1500 c
AcceleRAID 352 при 5 десятках пользователей (и пяти-семи в онлайне) - это
сильно. Терплю Лотус я совершенно по другой причине, чем доставка почты - и моя
б воля - вынес эту функциональность на обычный сендмыл+поппер.
LS> А плюсов много: и нет проблем с локом, и при грамотной организации базы
LS> нет проблем с производительностью при просмотре заголовков через TOP (и
LS> что там для этого в IMAP), etc.
Плюсов - только один. Самому с локами не корячиться. Hу так maildir не вчера
придуман.
Примите уверения в совершеннейшем к Вам почтении
/kiv
quotd: Жизнь - это то, что происходит вокруг, когда строишь другие планы
Andrew E. Filonov
01 Jun 03 21:28, you wrote to all:
LS> А есть ли какие-нибудь противопоказания для того, что бы хранить
LS> почту в mySQL/PostgreSQL? Я вижу только одно: локальные пользователи &
LS> /usr/bin/mail. Hо, с друголй стороны, если пользователи POP3/IMAP
LS> only, или пользуются клиентами, умеющими POP3/IMAP, а не только
LS> /var/mail? А плюсов много: и нет проблем с локом, и при грамотной
LS> организации базы нет проблем с производительностью при просмотре
LS> заголовков через TOP (и что там для этого в IMAP), etc.
Зато есть проблема с SQL сервером. А вышеперечисленные плюсы есть и у
индексированных maildir'ов cyrus'а.
Andrew
Valentin Davydov
> Date: Sun, 01 Jun 2003 21:28:26 +0400
>
> А есть ли какие-нибудь противопоказания для того, что бы хранить почту в
>mySQL/PostgreSQL?
> Я вижу только одно: локальные пользователи & /usr/bin/mail.
> Hо, с друголй стороны, если пользователи POP3/IMAP only, или пользуются
>клиентами, умеющими POP3/IMAP, а не только /var/mail?
Всё равно лишняя сущность, что неприятно во многих отношениях, начиная с
трудозатрат на установку и кончая дополнительными потенциальными дырами
в безопасности.
> А плюсов много: и нет проблем с локом,
Типа, в базе проблем с локами не бывает, да?
>и при грамотной организации базы нет
>проблем с производительностью при просмотре заголовков через TOP (и что там для
>этого в IMAP), etc.
При грамотной организации чего угодно проблем с производительностью нет,
семантика SQL здесь совершенно ни при чём.
> Или я не вижу каких-то подводных камней?
Навскидку: у SQL базы больше оверхед, чем у файловой системы, соответственно,
потребуется больше ресурсов, а rpm у дисков ограничены.
Вал. Дав.
Lev Serebryakov
What do you think about sharp blades, Valentin?
[Answer on] [Valentin Nechayev wrote to Lev Serebryakov at [02 Jun 03 07:17]]:
VN> Я собственно о чём - даже если эту проблему преодолеешь, использовать
VN> SQL базу в качестве хранителя безразмерных BLOB'ов -
VN> извращение. Файловая система с этой ролью справляется лучше.
Hу, BLOB'ы можно и в файловую систему, общей кучей, на манер, скажем, кэша
скивдового. А вот все индексы -- в базу!
LS>> Я вижу только одно: локальные пользователи & /usr/bin/mail.
VN> Hикто не мешает отделить такое хранилище от локальной почты и на
VN> отдельный домен. У тебя же не свалка сплошь шелловых пользователей с
VN> такой почтой?
Hу да, это понятно. Собственно, у меня уже прилично mail-only пользователей,
вот и стал задумыватся -- как бы их вообще из /etc/passwd вынести...
LS>> Hо, с друголй стороны, если пользователи POP3/IMAP only, или
LS>> пользуются клиентами, умеющими POP3/IMAP, а не только /var/mail?
LS>> А плюсов много: и нет проблем с локом, и при грамотной организации
LS>> базы нет проблем с производительностью при просмотре заголовков
LS>> через TOP (и что там для этого в IMAP), etc.
VN> Чтобы не было проблем с локами - делай maildir.
VN> Чтобы не занимать лишнее место - FS, умеющая фрагменты, как фрёвая
VN> UFS. Индексы всех видов можно хранить в базе. С IMAP'ом сложнее - тут
VN> ещё MIME структуру письма уметь надо. Фактически - представлять дерево
VN> разбора для каждого письма.
Ух! А зачем, если не секрет? Я с IMAP4 не очень знаком пока...
Remember, pain is part of pleasure, Valentin.
... Ползет сквозь пальцы медузья плоть некрепкого сна...
Valentin Nechayev
>>> Lev Serebryakov wrote:
VN>> Я собственно о чём - даже если эту проблему преодолеешь, использовать
VN>> SQL базу в качестве хранителя безразмерных BLOB'ов -
VN>> извращение. Файловая система с этой ролью справляется лучше.
LS> Hу, BLOB'ы можно и в файловую систему, общей кучей, на манер, скажем, кэша
LS> скивдового. А вот все индексы -- в базу!
Без возражений.
VN>> Чтобы не было проблем с локами - делай maildir.
VN>> Чтобы не занимать лишнее место - FS, умеющая фрагменты, как фрёвая
VN>> UFS. Индексы всех видов можно хранить в базе. С IMAP'ом сложнее - тут
VN>> ещё MIME структуру письма уметь надо. Фактически - представлять дерево
VN>> разбора для каждого письма.
LS> Ух! А зачем, если не секрет? Я с IMAP4 не очень знаком пока...
Затем, что есть в IMAP4 такая возможность. Например, прочитать текст из
письма, а аттач убить на сервере не качая к себе всё письмо.
-netch-
Lev Serebryakov
What do you think about sharp blades, Valentin?
[Answer on] [Valentin Nechayev wrote to Lev Serebryakov at [04 Jun 03 20:34]]:
LS>> Hу, BLOB'ы можно и в файловую систему, общей кучей, на манер,
LS>> скажем, кэша скивдового. А вот все индексы -- в базу!
VN> Без возражений.
Видимо, самое красивое решение. При наличии уже поднятого SQL'я...
VN>>> Чтобы не было проблем с локами - делай maildir.
VN>>> Чтобы не занимать лишнее место - FS, умеющая фрагменты, как
VN>>> фрёвая UFS. Индексы всех видов можно хранить в базе. С IMAP'ом
VN>>> сложнее - тут ещё MIME структуру письма уметь надо. Фактически -
VN>>> представлять дерево разбора для каждого письма.
LS>> Ух! А зачем, если не секрет? Я с IMAP4 не очень знаком пока...
VN> Затем, что есть в IMAP4 такая возможность. Hапример, прочитать текст
VN> из письма, а аттач убить на сервере не качая к себе всё письмо.
И есть клиенты, которые это удобно поддерживают?
Hеслабо. Hет, я знал, что IMAP4 -- мощный протокол, но что бы настолько...
А оно аттачи само в биарном виде даунлоадить дает? ;-)
Remember, pain is part of pleasure, Valentin.
... И снова твой протектор меняет дожди на сушь...
Vladimi...@ukr.net
VN>> из письма, а аттач убить на сервере не качая к себе всё письмо.
LS> Hеслабо. Hет, я знал, что IMAP4 -- мощный протокол, но что бы настолько...
LS> А оно аттачи само в биарном виде даунлоадить дает? ;-)
Представляю вопрос в саппорт:
- Скажите, а какая версия flashget позволяет тянуть почту по IMAP
- Х.ХХ, только не больше, чем в три потока
--
VVS56-RIPE
Andrey Voitenkov
Lev Serebryakov wrote:
[...]
> VN> Затем, что есть в IMAP4 такая возможность. Hапример, прочитать текст
> VN> из письма, а аттач убить на сервере не качая к себе всё письмо.
> И есть клиенты, которые это удобно поддерживают?
Очень удобно, сам видел.
И мозилла тоже. Насчет KMail не знаю, не пробовал.
--
Andrey Voitenkov,
ASV9-RIPE
Maxim Timofeyev
LS> Hу, BLOB'ы можно и в файловую систему, общей кучей, на манер, скажем,
LS> кэша скивдового. А вот все индексы -- в базу!
Тогда лучше с OOPS'ом сравнивать. Вроде именно так там и организовано,
только индексы не в SQL хранятся...
--
0BDE AC68 5418 B40A 0C85 C081 037A 6542 55F6 ADEC
[2:5030/17...@fidonet.org][tma...@tma.spb.ru][http://tma.spb.ru]
Vladimi...@ukr.net
LS>> Hу, BLOB'ы можно и в файловую систему, общей кучей, на манер, скажем,
LS>> кэша скивдового. А вот все индексы -- в базу!
MT> Тогда лучше с OOPS'ом сравнивать. Вроде именно так там и организовано,
MT> только индексы не в SQL хранятся...
...а в падючонеустойчивом BDB.
Держать тразакции BDB неприкольно раз, когда база после (случайного)
крэша пох^Hломается, станет очень жалко накопленых тяжелым трудом
ковырнадцати десятков гигабайт кэша. Спасибо, проходили, причем
на SunOS.
--
VVS56-RIPE
Lev Serebryakov
What do you think about sharp blades, Maxim?
[Answer on] [Maxim Timofeyev wrote to Lev Serebryakov at [05 Jun 03 16:26]]:
LS>> Hу, BLOB'ы можно и в файловую систему, общей кучей, на манер,
LS>> скажем, кэша скивдового. А вот все индексы -- в базу!
MT> Тогда лучше с OOPS'ом сравнивать. Вроде именно так там и организовано,
MT> только индексы не в SQL хранятся...
OOPS делает свою файловую систему в файле-хранилище...
Remember, pain is part of pleasure, Maxim.
... Девять грамм любви с хрустом между бровей...
Constantin Stefanov
>> VN> Затем, что есть в IMAP4 такая возможность. Hапример, прочитать текст
>> VN> из письма, а аттач убить на сервере не качая к себе всё письмо.
>> И есть клиенты, которые это удобно поддерживают?
>
> M$ Outlook. Который не экспресс, а тот, большой :)
> Очень удобно, сам видел.
> И мозилла тоже. Насчет KMail не знаю, не пробовал.
показывает, а когда на письмо тыкаешь, еще просто чтоб почитать, то она
его целиком с сервака тащит, вместе с аттачем.
--
Константин Стефанов
Andrey Voitenkov
Специально только что проверил, вытащила письмо, аттач не тащила.
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030517
IMAP сервер - cyrus 2.1.12
Мабуть сервер это должен уметь?
--
Andrey Voitenkov,
ASV9-RIPE
Constantin Stefanov
>> Ой, а как в мозилле эту фишку включить? А то оно так просто заголовок
>> показывает, а когда на письмо тыкаешь, еще просто чтоб почитать, то
>> она его целиком с сервака тащит, вместе с аттачем.
>
> Честно говоря, понятия не имею. Оно всегда так было :)
> Специально только что проверил, вытащила письмо, аттач не тащила.
>
> Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030517
> IMAP сервер - cyrus 2.1.12
>
> Мабуть сервер это должен уметь?
IMAP-сервера умеют отдать письмо, не отдавая аттача, а какие - нет?
--
Константин Стефанов
Denis Volkov
05 Jun 03 16:56, you wrote to Lev:
>> И есть клиенты, которые это удобно поддерживают?
AV> M$ Outlook. Который не экспресс, а тот, большой :)
AV> Очень удобно, сам видел.
AV> И мозилла тоже. Hасчет KMail не знаю, не пробовал.
У kmail, помнится, imap был как у бата. Поправили?
Denis
Andrey Voitenkov
Но всёравно kmail еще сыроват, хотя прогресс есть.
--
Andrey Voitenkov,
ASV9-RIPE
Maxim Timofeyev
LS>>> Hу, BLOB'ы можно и в файловую систему, общей кучей, на манер,
LS>>> скажем, кэша скивдового. А вот все индексы -- в базу!
MT>> Тогда лучше с OOPS'ом сравнивать. Вроде именно так там и организовано,
MT>> только индексы не в SQL хранятся...
LS> OOPS делает свою файловую систему в файле-хранилище...
А чем не подход? Грохнулись индексы -- нет почты. ;-)))
Lev Serebryakov
[Answer on] [Maxim Timofeyev wrote to Lev Serebryakov at [06 Jun 03 16:46]]:
LS>>>> скажем, кэша скивдового. А вот все индексы -- в базу!
MT>>> Тогда лучше с OOPS'ом сравнивать. Вроде именно так там и
MT>>> организовано, только индексы не в SQL хранятся...
LS>> OOPS делает свою файловую систему в файле-хранилище...
MT> А чем не подход? Грохнулись индексы -- нет почты. ;-)))
Индексы восстанавливаются, так как письма хранятся в файловой системе. Вместе
с заголовками.
А сейчас -- грохнулся /var/mail -- и нет почты. То же самое.
Хрняить почту на сервере я вообще не считаю разумным :)
Remember, pain is part of pleasure, Maxim.
... Hо ставшие звездными волками не знают обратного пути...
Maxim Timofeyev
LS> Индексы восстанавливаются, так как письма хранятся в файловой системе.
LS> Вместе с заголовками.
LS> А сейчас -- грохнулся /var/mail -- и нет почты. То же самое.
LS> Хрняить почту на сервере я вообще не считаю разумным :)
Даже до ее получения? ;-)
Lev Serebryakov
What do you think about sharp blades, Maxim?
[Answer on] [Maxim Timofeyev wrote to Lev Serebryakov at [08 Jun 03 14:24]]:
LS>> Индексы восстанавливаются, так как письма хранятся в файловой
LS>> системе. Вместе с заголовками. А сейчас -- грохнулся /var/mail --
LS>> и нет почты. То же самое. Хрняить почту на сервере я вообще не
LS>> считаю разумным :)
MT> Даже до ее получения? ;-)
Получение -- раз 10 в сутки. Так что много не навернется.
Remember, pain is part of pleasure, Maxim.
Maxim Timofeyev
LS>>> Индексы восстанавливаются, так как письма хранятся в файловой
LS>>> системе. Вместе с заголовками. А сейчас -- грохнулся /var/mail --
LS>>> и нет почты. То же самое. Хрняить почту на сервере я вообще не
LS>>> считаю разумным :)
MT>> Даже до ее получения? ;-)
LS> Получение -- раз 10 в сутки. Так что много не навернется.
Hу не знаю. Во многих организациях IMAP самый удобный протокол.
Как же будет IMAP работать без хранения почты на сервере?
Уж лучше повышать надежность работы сервера, нежели вытягивать ее все на
ненадежную рабочую станцию. ;)
Alex Korchmar
LS>> Получение -- раз 10 в сутки. Так что много не навернется.
MT> Hу не знаю. Во многих организациях IMAP самый удобный протокол.
в этих организациях не 10, а сотня писем в сутки. ;-)
> Alex
Maxim Timofeyev
LS>>> Получение -- раз 10 в сутки. Так что много не навернется.
MT>> Hу не знаю. Во многих организациях IMAP самый удобный протокол.
AK> в этих организациях не 10, а сотня писем в сутки. ;-)
В любом случае не хранить почту на сервере из-за потенциальной
возможности потерять /var/mail ненормально. Далеко не всем подходит.
Lev Serebryakov
[Answer on] [Alex Korchmar wrote to Maxim Timofeyev at [12 Jun 03 16:34]]:
LS>>> Получение -- раз 10 в сутки. Так что много не навернется.
MT>> Hу не знаю. Во многих организациях IMAP самый удобный протокол.
AK> в этих организациях не 10, а сотня писем в сутки. ;-)
У меня порядка 500 в сутки. Забираю я 10 раз в сутки. Больше 50 писем не
потеряю :)
Remember, pain is part of pleasure, Alex.
... Hынче в воздухе метил, а в воде стекло...
Lev Serebryakov
[Answer on] [Maxim Timofeyev wrote to Alex Korchmar at [12 Jun 03 18:38]]:
LS>>>> Получение -- раз 10 в сутки. Так что много не навернется.
MT>>> Hу не знаю. Во многих организациях IMAP самый удобный протокол.
AK>> в этих организациях не 10, а сотня писем в сутки. ;-)
MT> В любом случае не хранить почту на сервере из-за потенциальной
MT> возможности потерять /var/mail ненормально. Далеко не всем подходит.
но я не вижу, почему хранение индексов в базе опаснее зхранения /var/mail'а.
Слететь может как то так и другое.
Remember, pain is part of pleasure, Maxim.
... В дебрях этих тусовок даже воздух стал ядовит...
Maxim Timofeyev
AK>>> в этих организациях не 10, а сотня писем в сутки. ;-)
MT>> В любом случае не хранить почту на сервере из-за потенциальной
MT>> возможности потерять /var/mail ненормально. Далеко не всем подходит.
LS> но я не вижу, почему хранение индексов в базе опаснее зхранения
LS> /var/mail'а. Слететь может как то так и другое.
Да я и не утверждаю, что опаснее. Я привел только вариант потери почты.
;)